1. Field of the Invention
Digital libraries and content management systems need to support large objects as components of high-level concepts such as documents. These objects are typically accessible through an application programming interface (API) provided by the system. This design causes performance and interfacing problems, as well as high costs to ingest legacy objects into the system. This invention offers an object server that provides a cache with a file-based fast-path to the objects stored in the object server, without compromising the integrity of the system, including a content model, constraints, and access control.
2. Description of Related Art
A network-based system, such as the World Wide Web, a content management system, such as the document/image management system Visuallnfo.TM., or a multimedia library system, such as a digital library, usually provides Library Server functions as well as Object Server functions. These functions can run on one or more network server nodes.
A Library Server typically supports a high-level content model, handles access control, manages transactions, and performs other functions. An Object Server, on the other hand, supports a large, scaleable repository of objects which are components of the high-level content model maintained by Library Server. To protect the content, for integrity (model, functions, relationships, constraints) and security (access control), these objects are normally accessible only through the API provided by the system.
While this design is rational, it creates a number of performance and interface problems when the system is used to support large applications. These problems include:
1. An object is often copied several times on the way to or from an Object Server, passing from one software component or process to another. PA1 2. An application cannot access an Object Server directly if the API is not available on the client computer executing the application. This is the case in the World Wide Web environment. PA1 3. There is no direct delivery of object to a third party. For example, one or more originating applications may interactively select objects for asynchronous or deferred processing (e.g., batch processing) by another application which does not have the same Library Server access privileges as the originating applications. The originators must retrieve the objects and send them to the other application, i.e., the latter has to get the objects indirectly. PA1 4. Most third-party applications and tools use and access files. A proprietary API prevents inter-operation and integration. PA1 5. It is expensive to load a large amount of legacy objects, usually files, into the system.
These difficulties are sought to be minimized by the present invention.